The industry organization, SyncML Iniative, founded in February, 2000, aims at formulating a standard specification which enables synchronization of personal information and data within enterprises over multiple platforms and networks. The purpose of developing SyncML is to enable the end-user, device developer, infrastructure developer, data provider, application software developer as well as service provider to cooperate with each other and tangibly achieve the goal of accessing any network data anytime and anywhere using any terminal device. A typical application for SyncML data synchronization is the data synchronization between mobile devices or application servers, and network servers. In addition, SyncML may be further applicable to data synchronization between peer-to-peer entities, such as between two PCs.
FIG. 1 illustrates a schematic system diagram of implementing data synchronization. The system for implementing synchronization includes a SyncML client and a SyncML server. After the SyncML client and server implement a parameter negotiation in synchronization initialization stage, they exchange their modified data so as to ensure data synchronization between the two parties.
Data synchronization can be categorized into a plurality of types, which are detailed in Table 1 for reference.
TABLE 1Data Synchronization TypeSync TypeDescriptionTwo-wayTwo-way sync is a normally used synchronization approachsyncin which the sync client and server simply exchange (donot exchange the unmodified) information about modifieddata in these devices. The client sends the modificationinformation first.Slow syncSlow sync is a special type of two-way sync. Thedifference lies in that the data must be compared on apiece-by-piece and field-by-field basis, which meansthat, during synchronization, both the client and theserver shall send all the data in a local database tothe other side and then the server or client does thesynchronization analysis between each piece of receiveddata and each piece of data that it stores on a field-by-field basis.One-wayOne-way sync from client only is a one-way syncsync fromapproach. Only the client sends its information aboutclient onlydata modification to the server. The server does notsend its modification information to the client.RefreshRefresh sync from client only is a one-way syncsync fromapproach. The client sends all the data in the localserver onlydatabase to the server. The server replaces all thedata in the database of the server with the data fromthe client. In other words, the data in the server isidentical to the data in the client, without any lessor more, or different records.One-wayOne-way sync from server only is similar to one-waysync fromsync from client only. Only the server sends itsserver onlyinformation about data modification to the client. Theclient does not send its modification informationto the server.RefreshRefresh sync from server only is similar to refreshsync fromsync from client only. The server sends all the userserver onlydata in the database to the user client. The clientreplaces all the data in the client database with thedata from the server. In other words, the data in theclient is identical to the data in the server, withoutany less or more, or different records.ServerThe server alerted sync refers to that the serverAlertedfirst alerts the client to perform a synchronizationSyncoperation. In other words the server informs the clientto start a specific type of the synchronizationoperation. Only the server informs the client andrequests the client to initiate a type ofsynchronization. The subsequent synchronizationprocedure may be the above six synchronization types.
The two-way synchronization is provided below merely as an example illustrating the process of data synchronization in detail. The other synchronization types are special scenarios of the two-way synchronization. For instance, the slow synchronization may be regarded as two-way synchronization in which the client and the server send all the data; the one-way synchronization is two-way synchronization in which the synchronization data is sent in one-way direction; the refresh synchronization is slow synchronization in which the synchronization data is sent in one-way direction.
Referring to FIG. 2, the synchronization procedure specified in the SyncML specification are typically divided into three stages:
The first stage, steps Pkg#1-Pkg#2, is a synchronization initialization stage, in which the SyncML client and server primarily perform identity authentication and a device capability negotiation, the device capability including data associated with the device, such as OEM, model, version, and the like; data associated with synchronization data, such as supported synchronization data types, properties, parameters, and the like; data associated with data storage, such as data storage capability, synchronization data type and method supported by the storage, and the like; and data associated with extension mechanism, such as the name of extension element and the like. The interaction process during this stage usually lasts for several times before completion.
During this stage, in the initialization message (SyncML Initialization Message) sent by the synchronization client (Data Sync Client, hereinafter “DS client”), the device capability of the client is included in its command tag <Put>; its command tag <Get> is used to request device capability of the synchronization server (Data Sync Server, hereinafter “DS server”). If the DS client does not require device capability of the server, the client may not send <Get> command.
The positions of DS client and DS server are equal. If the DS client does not use <Put> command to send device capability, the DS client may use <Get> command to request the client to send the device capability.
The next stage is entered only after the client and server fully completes identity authentication and a device capability negotiation.
The second stage, steps Pkg#3-Pkg#4, is a synchronization stage, which is mainly used in one of the client and server. According to the status of the data, such as Add, Update, Delete, and Move, the changed data is sent to the other end (the client or server) by operation command and the other end performs the same operation according to these commands to achieve synchronization purpose.
The third stage, steps Pkg#5-Pkg#6, is a synchronization completion stage which is mainly used in confirming by the client and server the completion of synchronization with each other.
The inventors of the present invention found at least the following issues in terms of the prior art in the course of creating the present invention. Generally, all of the prior arts include a device capability negotiation process during synchronization initialization. Such process takes relatively a lot of time so that the data synchronization process is unnecessarily be prolonged, resulting in a lower synchronization efficiency. The details can be deduced through the below analysis.
It can be seen from the existing synchronization procedure that the synchronization initialization needs to be executed initially every time before the data synchronization is performed, and the synchronization initialization generally includes a a device capability negotiation process. However, in practice, the device capability does not change frequently. Even if the device capability is changed, it is likely that only parts of the information changes. Furthermore, sending all the device capability would lead to a huge amount of data, which prolongs the time for data synchronization accordingly.
In addition, because the existing device capability includes descriptions associated with data format, there exists a coupling relationship between the data synchronization protocol and the data to be synchronized. In other words, every time a new data format is added, or the device capability is modified, the data synchronization specification will be somewhat affected.
It is apparent that improving the synchronization efficiency is an impending issue that needs to be solved.